This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


~Karl Quetjumitherikle
Mar 28, 2013, 9:43 AM
8 Posts

RE: Redirect TCP to SSL setting and infinite redirection

  • Category: Domino Server
  • Platform: Windows
  • Release: 9.0
  • Role: Administrator
  • Tags: HTTP,SSL,Security
  • Replies: 24

Mike,

I did some additional tests with SSL redirect enabled at Internet site configuration level.

Authentication has no effect. I tested my test server with and without session authentication. Even a database with anonymous access allowed causes the problem. According to thread logs, if we request such a database resource, it stops at the authentication level and return to redirection.

I have also tried using different host names to check if the problem is related to host-name binding but it doesn't matter.

Interestingly, the only page I can reach is /names.nsf?login. I can reach this page, see the login form (without images) but authentication doesn't change anything (it doesn't get authenticated, no cookies).

 

 

*** Start SSL Handshake: Session 2a, Thread 7d74, Clock 100231
*** SSL Handshake Success: Session 2a, Thread 7d74, Clock 100246
*** New Request -- Parse and Check Request: Session 2a, Thread 7d74, Clock 100246
GET /names.nsf?login HTTP/1.1
Host: mobile1.developi.info
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,tr;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
 
*** Process Request: Session 2a, Thread 7d74, Clock 100246
*** Client IP Address [127.0.0.1], Server IP Address [127.0.0.1]: Session 2a, Thread 7d74, Clock 100246
 
*** Start Request Step: Session 2a, Thread 7d74, Clock 100246
*** Raw Request Step: Session 2a, Thread 7d74, Clock 100246
*** Pre Authenticate Step: Session 2a, Thread 7d74, Clock 100246
*** Post write Buffer, bytes [205]: Session 2a, Thread 7d74, Clock 100246
 
 
HTTP/1.1 200 OK
 
Server: Lotus-Domino
 
Date: Thu, 28 Mar 2013 09:36:24 GMT
 
Expires: Tue, 01 Jan 1980 06:00:00 GMT
 
Content-Type: text/html; charset=UTF-8
 
Content-Length: 6299
 
Cache-control: no-cache
 

I get the login form after that, and submit username password;

 

 

*** Start SSL Handshake: Session 17d, Thread 7d74, Clock 431359
*** SSL Handshake Success: Session 17d, Thread 7d74, Clock 431374
*** New Request -- Parse and Check Request: Session 17d, Thread 7d74, Clock 431374
POST /names.nsf?Login HTTP/1.1
Host: mobile1.developi.info
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,tr;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 91
 
*** Process Request: Session 17d, Thread 7d74, Clock 431374
*** Client IP Address [127.0.0.1], Server IP Address [127.0.0.1]: Session 17d, Thread 7d74, Clock 431374
 
*** Start Request Step: Session 17d, Thread 7d74, Clock 431374
*** Raw Request Step: Session 17d, Thread 7d74, Clock 431374
*** Pre Authenticate Step: Session 17d, Thread 7d74, Clock 431374
*** Authenticate Step: Session 17d, Thread 7d74, Clock 431374
*** Post write Buffer, bytes [176]: Session 17d, Thread 7d74, Clock 431374
 
 
HTTP/1.1 302 Found
 
Server: Lotus-Domino
 
Date: Thu, 28 Mar 2013 09:41:55 GMT
 
Connection: close
 
 
Content-Length: 0
 
 
 
 
*** End Request Step: Session 17d, Thread 7d74, Clock 431374
*** Log Request: Session 17d, Thread 7d74, Clock 431374
 

 

The problem might be related to authentication, but it acts strange. I tried turning off Name & Password authentication for SSL, the problem still continues. 

 

~Arnold Frofreeburoni
Mar 28, 2013, 4:15 PM
27 Posts
We still cannot reproduce
No matter what we have done, set redirection settings in both internet sites, web configuration view and on database properties we have not been able to reproduce the issue.  We have tried this on new/overlay installs on many machines and we cannot reproduce the problem (very frustrating).  Even some of our internal 90 servers that have these settings do not exhibit this issue.  

The only explanation we have is that It appears that some context that is passed into the Domino Web App Layer is clobbered or not set for some reason and the code thinks the connection is not ssl, so it does a redirect.  There are no code changes in these areas so it is a mystery why this is happening in some environments and not others.

In all cases that have been uploaded with regard to the Redirect TCP to SSL settings in the NAB, the request processing has already gone by the check that is made by the http stack, so the http stack is not doing the redirect to ssl and is correctly seeing the network connection is ssl. The  redirect is being done in a different location.

If the http stack does the redirection one sees the following sequence in the htthr* log files (see below)

You will notice that if the http stack does the redirection, you will NOT see any of the processing steps, like the following, see the log example below from my attempt to reproduce.

*** Start Request Step: Session 2, Thread 281c, Clock 67860
*** Raw Request Step: Session 2, Thread 281c, Clock 69358
*** Pre Authenticate Step: Session 2, Thread 281c, Clock 69358
*** Authenticate Step: Session 2, Thread 281c, Clock 69373

 
In your case below, you see the following steps in the log, which means the http stack check of the Redirect tcp to SSL flag in the NAB has already been done and has not resulted in a redirect.  It looks like checks done in the authentication code is causing the redirect.  And it appears that can only happen only if the code fails the ssl connection check, bad context.

*** Start Request Step: Session 17d, Thread 7d74, Clock 431374
*** Raw Request Step: Session 17d, Thread 7d74, Clock 431374
*** Pre Authenticate Step: Session 17d, Thread 7d74, Clock 431374
*** Authenticate Step: Session 17d, Thread 7d74, Clock 431374
*** Post write Buffer, bytes [176]: Session 17d, Thread 7d74, Clock 431374
 

In the other cases with mail the redirect occurred in process request step and was also pass the http stack Redirect TCP to SSL check.  That also may point to some context that was clobbered/incorrect.

I may be helpful to know all of your security settings (many of them do have interactions with other settings).

Thanks for the update

One of my attempts to reproduce, I get the login page and when I login I will get the resource over ssl, I have tried all the combinations I can think of, and our QE has also attempted to independently reproduce but still no joy.


*** New Request -- Parse and Check Request: Session 0, Thread 281c, Clock 66674
GET /foo.txt HTTP/1.1
Host: xxx..ibm.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive

*** Process Request: Session 0, Thread 281c, Clock 66690
*** Client IP Address [x.xx.xxx.xxx], Server IP Address [x.xx.xxx.xxx]: Session 0, Thread 281c, Clock 66690

HTTP STACK DOES THE REDIRECTION HERE AND PROCESSING ENDS, NOTICE NO REQUEST STEPS.

*** Post write Buffer, bytes [165]: Session 0, Thread 281c, Clock 66690


HTTP/1.1 302 Found
Server: Lotus-Domino
Date: Thu, 28 Mar 2013 16:06:20 GMT
Connection: close
Location: https://xxx.ibm.com/foo.txt
Content-Length: 0


*** Log Request: Session 0, Thread 281c, Clock 66690

*** Start SSL Handshake: Session 2, Thread 281c, Clock 67720
*** SSL Handshake Success: Session 2, Thread 281c, Clock 67735
*** New Request -- Parse and Check Request: Session 2, Thread 281c, Clock 67829
GET /foo.txt HTTP/1.1
Host: xxx..ibm.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive

*** Process Request: Session 2, Thread 281c, Clock 67860
*** Client IP Address [x.xx.xxx.xxx], Server IP Address [x.xx.xxx.xxx]: Session 2, Thread 281c, Clock 67860

*** Start Request Step: Session 2, Thread 281c, Clock 67860
*** Raw Request Step: Session 2, Thread 281c, Clock 69358
*** Pre Authenticate Step: Session 2, Thread 281c, Clock 69358
*** Authenticate Step: Session 2, Thread 281c, Clock 69373
*** Post write Buffer, bytes [205]: Session 2, Thread 281c, Clock 69373


HTTP/1.1 200 OK
Server: Lotus-Domino
Date: Thu, 28 Mar 2013 16:06:23 GMT
Expires: Tue, 01 Jan 1980 06:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1369
Cache-control: no-cache

This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal